Companies that provide items such as finished goods or raw materials have a lot of choice in how the items are shipped (in the sense of parcel shipping). If choices are made correctly, the shipper can realize significant savings. The choices, however, are complex enough that having to analyze options for any particular shipping requirement is likely to overwhelm the typical shipping department employee. Although making a choice in how to ship a parcel could be automated for any particular shipper (the sender, not the carrier), the cost of doing so is great enough that most shippers would be reluctant to go ahead with automating the shipping options analysis.
The principal elements of planning the shipping of a parcel or a batch of parcels are first, determining a route for the parcel or each parcel in a batch of parcels (called routing), and second, determining a rate for the parcel or for each parcel in the batch of parcels. In planning for a single parcel, only routing and rating are performed. In planning for shipping a batch of parcels, it is also desirable to examine opportunities to consolidate the parcels, and if some shipments can be consolidated, to prorate the costs of shipping each consolidated parcel (i.e. to apportion the costs of a load of several consolidated shipments of parcels among the individual parcels).
Given an overall system for managing parcel shipping, such as that disclosed in the related application, “SYSTEM FOR MANAGING PARCEL SHIPPING,” what is needed is a planning module for helping analyze the many options available for shipping a parcel of items, and ideally one that is versatile enough, in how it can plan for shipping a parcel, that it is suitable for a great many different kinds of shipper.
Further what is needed is a planning module that can be used (called) either to plan for shipping either a particular parcel, or to plan for shipping a batch of parcels.
Still further what is needed is a planning module that can acquire inputs used in planning a shipment or shipments either from non-volatile memory (such as from a database stored on a computer disc storage device) or from volatile memory (RAM).
Still further what is needed is a planning module that can be called by other modules without its having to be included in a single build of a comprehensive module (in the sense of components linked together in a static build) including the calling modules and the planning module.
Still further what is needed is a planning module that itself can call other modules each providing a specific service, such as a routing service or a rating service, without having to be included in a single (statically linked) build of a comprehensive module including the planning modules and the modules it calls for services.